The Web Services Description Language (WSDL) is an XML format for describing network services offered by a server. See http://www.w3.org/TR/2001/NOTE-wsdl-20010315. This specification assumes the reader is familiar with XML, XSD, SOAP, and WSDL. This technology space is well known and written about in the computer arts. Generally, WSDL is used to create an XML textual description of services provided by a network server and a set of operations within each service. WSDL describes the format that a client uses to request services. WSDL service description is used by the client and server to communicate in an agreed XML format. The server agrees to provide certain services only if the client sends a properly formatted XML request.
Programmers use WSDL to form proper messages and service requests, and proper message responses and service request responses. A client obtains a copy of the WSDL description, and uses the information in this file to format a conforming request. Upon receiving a compliant request, the server can complete an operation and return the results to the client in a WSDL compliant format.
In a general sense, FIG. 1 depicts how WSDL, SOAP, XSD, and XML support message passing and web services over a network 106 between computer systems 102, 104. WSDL is computing environment agnostic, meaning, so long as a client communicates in XML according to the WSDL definition, it makes little difference whether the client and server exist in compatible computing environments (e.g., COM, JAVA, CORBA, etc). Since WSDL describes a textual representation for message passing and invoking web services in XML, a WSDL compliant communication can be recognized and translated by any computer environment following the WSDL standard.
As shown in FIG. 1, XML and SOAP are specified on both computers 102, 104. However, in some cases WSDL and XSD are not specified on both computers. In one case, a client 104, may not have WSDL and XSD specified locally, as indicated by the dotted lines 108. In this case, the client 104 parses the server's 102 WSDL and XSD, and sends the server a SOAP message which corresponds with the server WSDL. In some cases, many computers access a server to parse a WSDL and/or XSD.
A WSDL document contains the following elements in the definition of network services as shown in Table 1.
TABLE 1Types—A container for data type definitions using some type system(such as XSD).Message—An abstract, typed definition of the data being communicated.PortType—An abstract set of operations supported by one or more end-points.Binding—A concrete protocol and data format specification for aparticular port type.Port—A single endpoint defined as a combination of a binding and anetwork address.Service—A collection of related endpoints.
As shown in FIGS. 2 and 3, the WSDL document structure is a set of definitions. There is a definitions element at the root 302, and definitions inside the document. The grammar of the WSDL document format is followed by the server that is providing services to its clients so as to allow any client to understand the syntax of the messages accepted by the server. As discussed in Table 1,the WSDL document may contain types 304, messages 306, port types 308, bindings 402, and services 404.
The namespace prefixes described in Table 2,along with the syntax and rules described in Table 3,are used in this specification. Namespaces are a way to uniquely identify elements and attributes within a document.
TABLE 2prefixnamespace URIdefinitionwsdlhttp://schemas.xmlsoap.org/WSDL namespace for WSDL framework.wsdl/soaphttp://schemas.xmlsoap.org/WSDL namespace for WSDL SOAP binding.wsdl/soap/httphttp://schemas.xmlsoap.org/WSDL namespace for WSDL HTTP GET &wsdl/http/POST binding.mimehttp://schemas.xmlsoap.org/WSDL namespace for WSDL MIME binding.wsdl/mime/soapenchttp://schemas.xmlsoap.org/Encoding namespace as defined by SOAP 1.1soap/encoding/soapenvhttp://schemas.xmlsoap.org/Envelope namespace as defined by SOAP 1.1soap/envelope/xsihttp://www.w3.org/2001/XInstance namespace as defined by XSDMLSchema-instancexsdhttp://www.w3.org/2001/XSchema namespace as defined by XSDMLSchematns(various)The “target namespace” (tns) prefix is used asa convention to refer to the current document.(other)(various)All other namespace prefixes are samplesonly. In particular, URIs starting with“http://example.com” represent someapplication-dependent or context-dependentURI
TABLE 3The syntax appears as an XML instance,but the values indicate the data typesinstead of values.Characters are appended to elements andattributes as follows: “?” (0 or 1), “*” (0or more), “+” (1 or more).Elements names ending in “...”(such as <element...> or </element...>) indicatethat elements/attributes irrelevant to the context are being omitted.<-- extensibility element --> is aplaceholder for elements from some “other”namespace (like ##other in XSD).The XML namespace prefixes (defined below)are used to indicate the namespaceof the element being defined.Examples starting with <?xml containenough information to conform to thisspecification; others examples are fragmentsand require additional information tobe specified in order to conform.
Using the WSDL document structure shown in FIGS. 2 and 3, and an example program (“CEchoString”) shown in FIG. 4, a WSDL description of CEchoString is shown in FIG. 5.
For example, a server can publish, deliver, or otherwise make available, a copy of the WSDL description of CEchoString to a client. The client can use the description to send web service requests and responses. The client computer system includes software that sends and receives XML messages that comply with the description. The server computer system includes software that receives and sends messages according to the description. Both client and server may include software that translates the XML messages into their respective implementation environment.
Thus, a network server provides a WSDL description of the services it provides. Some of the messages sent to the server will have parameters, and some of these parameters may contain trees of objects. For example, given the XML message contained in FIG. 6, the trees of objects shown in FIG. 7 can be constructed.
The described extensions are directed towards providing type-centric descriptions to web service description languages. The extensions illustrated herein provide the constructs to describe and implement a type-centric, object-model agnostic, web service description. By implementing the constructs described herein, a heterogeneous distributed computing environment can implement rich type-centric services.
A few of the web services describable by this extended type-centric web service description language include support for representing graph data structures through its definition of the syntax for multi-reference pointers, for representing remote objects passed by-reference through its definition of service reference wire datatype, for discovering the type of a remote object at runtime through the definition of a service interface, and other type-centric constructs such as classes, interfaces, properties, events, and delegates. With this extended web service description language, a server can provide a type-centric, object-model agnostic description of a web service.
The type extensions described herein allow many added features. A few of these features are included for example purposes. In one respect, in a graph description, a type description indicates whether a type is encoded as a reference or embedded within another type. In another respect, in a service reference description, a type description indicates whether a type is remoted by-value or by-reference. In several other respects, a type description indicates that, a service extends another service, a service implements an interface (potentially multiple interfaces), or a field of a type (including interfaces) is a reference type, a constant value field, or a bit field type that defines enumerations with associated values.
In another respect, the type extensions provided the ability to define properties on types, to set enumeration values and types, to compose services including with other services, and to specify an array syntax.
Additional features and advantages will be made apparent from the following detailed description which proceeds with reference to the accompanying drawings.